Module 10 Closure
Spring 2010
Compiled by Greg Kinney
“MUDDIEST ITEMS”:
QUESTION:
The muddiest item referred to the discussion involving early finish “Goldratt feels that project workers will avoid admitting that an activity has been completed early”. I have been involved in many projects over many years and it has been a rare occasion to come across a worker that doesn’t want to admit an activity they were assigned was completed early. Isn’t that one of the goals of the worker or manager assigned to the task – to complete it early? I am assuming that Goldratt refers to “sandbagging” a task to fill the estimated completion time. But most experienced workers or managers have learned that if anything goes awry with these “sandbagged” tasks, they invariably become late. On some projects, “early” is “on time”.
ANSWER:
Goldratt is trying to explain why early finishes don’t translate to early starts for the next task. I am with you on this point; I am not convinced there is a disincentive for workers to say that we’re done early, unless (as you say) they really are sandbagging. That begs the question of why, then, the next task doesn’t start right away. My personal feeling is that there are often factors that cause that to happen. For instance, if a crew has a backlog, and is finished up early at one job, the boss may notice they’re ahead of schedule so can temporarily go to another job at another site to catch up there. Also it depends on the nature of the next task. The planners may have scheduled material deliveries to arrive just a day or two ahead of planned start – or maybe materials are late. Those kinds of factors also push you right back to the planned start date (or later), and negate the benefits of an early finish on the critical path.
QUESTION:
The muddiest thing for me definitely was the section of heuristics. It didn’t seem very intuitive to me and I still have a bit of trouble actually following it.
ANSWER:
I think of heuristics as a fancy term for what are usually called iterative or cut-and-try methods. But it also includes “programming” style methods for getting at an optimal answer under given assumptions. The big thing is that there is a procedure. Check out the discussion of SPAR-1 on page 468 as an example of resource allocation heuristics.
QUESTION:
The least clear thing I learned from this module was how “fast-tracking” is different from crashing (see p. 442-443). Can you explain? It seems like they are one in the same.
ANSWER:
Crashing is something that is typically done after plans are completed when, for whatever reason, making schedule is more important than controlling costs. That’s when you’re authorizing overtime or going to double shifts, you’re bringing on extra workers, you’re accelerating materials (maybe even ordering more than you otherwise would), you’re getting expensive equipment, all to boost production more than would normally be justified – just to compress the schedule.
Fast tracking is a little different concept, even though it is a schedule compression strategy. What you’re doing in fast tracking is setting up activities in parallel. Most notably, the design proceeds just ahead of construction. As you know, conventional practice is to release design packages as a whole, which the contractors can then bid on as a whole. In fast tracking, it will all be done in staged or partial releases. Partial Release A may just be the site preparation – cut, fill, compaction etc. Partial Release B may be site utilities (water, sewer, storm drain). Partial Release C may be the foundation work, and so on. This is a generally inefficient process that is also high risk, since it may turn out that complications discovered in later stages cause rethinking and rework of what was done earlier. It also requires ongoing and intense collaboration between all parties. There are many things that can go wrong. This approach can succeed brilliantly. It can also be a spectacular disaster.
QUESTION:
The muddiest part was crashing a project. I understand the idea, but the method of moving times and resources around and looking at the effect on the cost seemed very arbitrary especially when the project is very complicated.
ANSWER:
This is something that will become a little easier with practice. You want to play around with the most schedule compression but with the least dollars to do it. In practice problems, you’ll have a normal and a crashed costs and schedules for each task. The point of the exercise is that you can get the maximum benefit in terms of schedule compression by crashing some tasks but not all of them. If you crash all of them, you will spend lots of money, but if you crash tasks that are outside the crashed critical path, you may get no return on the additional investment. This is something best approached just by trying.